Enable OpenShift cluster deployment via Pulumi on GCP and local environments - #1591
Conversation
…lly start a CRC cluster
…rocess for CRC Cluster
Co-authored-by: Lénaïc Huard <L3n41c@users.noreply.github.com>
…t open: Permission denied errors I recieved when testing locally
| OSCommand: command.NewUnixOSCommand(), | ||
| }) | ||
|
|
||
| pullSecretPath := os.Getenv("PULL_SECRET_PATH") |
There was a problem hiding this comment.
Why do we need it to be passed as an environment variable? Can we make it a params of the function instead?
There was a problem hiding this comment.
Updated the setup too use function params instead of env variables by reading the pull secret path from Pulumi config in openshift.go, adding support for invoke gcp.create-openshift.go in tasks/gcp/openshift.py, and updating setup.py to optionally prompt for the path in invoke setup
| "github.com/pulumi/pulumi/sdk/v3/go/pulumi" | ||
| ) | ||
|
|
||
| func NewLocalOpenShiftCluster(env config.Env, name string, opts ...pulumi.ResourceOption) (*Cluster, error) { |
There was a problem hiding this comment.
What are the condition to be able to run that locally? Is it working on MacOS laptops?
There was a problem hiding this comment.
This was a commit where I ran the function and confirmed it worked on macOS. I modeled this after the unused NewLocalKindCluster setup. In both situations the local setups aren't referenced anywhere, so I'm fine with removing it if you think that's appropriate.
There was a problem hiding this comment.
Actually the NewLocalKindCluster setup is used in a provisioner on datadog-agent side: https://github.com/DataDog/datadog-agent/blob/main/test/new-e2e/pkg/provisioners/local/kubernetes/kind.go#L132
The goal is provide a local setup that allows you to iterate faster when creating a test for the first time
There was a problem hiding this comment.
Ah, I see. I’ve implemented functionality for passing the pull secret as a parameter for both the local cluster and cluster on GCP. However, I didn’t add an invoke command for the local cluster creation to keep consistency with other cluster types. For the datadog-agent integration, I anticipate needing to adapt the pull secret config approach. Currently, the GCP OpenShift cluster receives the pull secret through the invoke setup process, but the datadog-agent environment may require a different configuration pattern. I’d appreciate any guidance for how to handle that…
| AllowStoppingForUpdate: pulumi.Bool(true), | ||
| AdvancedMachineFeatures: &compute.InstanceAdvancedMachineFeaturesArgs{ |
There was a problem hiding this comment.
Are these ones supported for all the machine types? I know that on AWS you can only enable nested virtualization on specific machines
There was a problem hiding this comment.
On GCP, nested virtualization is only supported on specific machine types like N1, N2, etc., and not on E2 or shared-core instances. I chose n2-standard-8 to meet vCPU and memory needs for CRC. Also, it also supports nested virtualization, which is needed to run CRC inside a VM on GCP.
There was a problem hiding this comment.
In that case what happens if we set instanceType to a type that does not support nested virtualization? Your change enforce the NestedVirtualization to be enabled all the time, so I am afraid it will break when some instance type are used. Maybe we should make it configurable?
There was a problem hiding this comment.
I’ve addressed the nested virt concern by making the feature configurable. EnableNestedVirtualization now defaults to false for all GCP VM instances, with the OpenShift scenario setting it to true. I also removed the AllowStoppingForUpdate setting as I had added it only for testing. Also dropped the new WithInstanceType function I introduced in vmargs.go after realizing I could leverage the existing ddinfra:gcp/defaultInstanceType configuration.
| package openshiftvm | ||
|
|
||
| import ( | ||
| localKubernetes "github.com/DataDog/test-infra-definitions/components/kubernetes" |
There was a problem hiding this comment.
Let's not alias it localKubernetes here, because it actually create the openshift cluster in a remote VM on GCP
| "scenario": scenario_name, | ||
| "ddinfra:env": f"gcp/{cfg.get_gcp().account}", | ||
| "ddinfra:gcp/defaultPublicKeyPath": cfg.get_gcp().publicKeyPath, | ||
| "ddinfra:openShiftPullSecretPath": pull_secret_path, |
There was a problem hiding this comment.
Let's call the parameter ddinfra:gcp/openshift/pullSecretPath since it is related to GCP and openshift only.
with that you will need to add that parameter here: https://github.com/DataDog/test-infra-definitions/blob/main/resources/gcp/environment.go#L28
And create the corresponding helper funcition to retrieve that parameter from the Pulumi config map, for example: https://github.com/DataDog/test-infra-definitions/blob/main/resources/gcp/environment.go#L159C1-L162C2.
You should then be able to use that helper in openshiftvm/run.go to retrieve the image pull secret parameters, and pass it to NewOpenShiftCluster function that creates the openshift cluster component
…r openshift, removed withinstancetype func, change ddinfra name, etc
What does this PR do?
This PR introduces support for provisioning an OpenShift cluster via Pulumi. More specifically, it adds:
NewOpenShiftClusterincomponents/kubernetes/openshift.goto provision an Openshift cluster on a remote VM.NewLocalCRCCLusterfor testing CRC clusters locallygcp/openshiftvmthat provisions a GCP VM with nested virtualization and deploys an OpenShift cluster on itresources/gcp/compute/vm.goto support:scenations/gcp/compute/vmargs.gofor setting custom OS descriptorsWhich scenarios this will impact?
gcp\openshiftvm, available in theScenarioRegistryMotivation
Usage
invoke setupand set the pull secret path using it. Then runinvoke gcp.create-openshiftandinvoke gcp.destroy-openshiftinvoke gcp.create-openshift -p <pull_secret_path>andinvoke gcp.destroy-openshiftAdditional Notes
Manual verification steps for the cluster are:
eval $(crc oc-env)oc login -u kubeadmin https://api.crc.testing:6443(password retrieved fromcat ~/.crc/machines/crc/kubeadmin-password)oc get nodesThe instance type
n2-standard-8was chosen because CRC requires at least 4 vCPUs and 9 GiB of RAM to function, and n2-standard-8 provides 8 vCPUs and 32 GiB of memory; additionally, it supports nested virtualization, which is needed for running CRC inside a VM on GCP